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(54) System and method for programmatically creating a graphical program 

(57) A system and metliod for programmati* the existing graphical program, 
caily/dynamicaily creating or editing a graphical pro- 
gram. A first program may be created, wherein the first 
program specifies creation of a new graphical program. 
When the first program is executed, the new graphical 
program Is programmatically created, in response to 
executing the first program. Thus, during execution of 
the first program, the first program Is operable to cause 
creation of the new graphical program. The first pro- 
gram may specify the inclusion of various objects in the 
new graphical program. For example, the new graphical 
program may have a diagram portion including a plural- 
ity of interconnected nodes which visually Indicate func- 
tionality of the new graphical program. The new 
graphical program may also have a user interface por- 
tion including various user interface objects. In a related 
embodiment, a first program may specify the modifica- 
tJon of an existing graphical program. When executed, 
the first program causes the existing graphical program 
to be modified, e.g., by modifying various objects of the 
graphical program. The first program may call an appli- 
cation programming interface (API) usable for program- 
matically creating a new graphical program or modifying 
an existing graphical program. The first program may be 
operable to interface with a server program, e.g., a 
graphical programming development environment appli- 
cation, in order to programmatically request the server 
program to create the new graphical program or modify 
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nr progtammatically creating a gtaphicat program. 



Description of the Relatad Art 

S!^f ronT ahH™'"?"!'"^ •^■^'^ programming languages exist. Indudlns BASIC. C. FO^Rm. 
S ^„«^ ' ^ P'^.S™™ **en In these high level languages are translated to the machine language 

Sir ^SST ^ " "*«'P'«Bre. -me high level text-based programming languages in this lA«l, 

« ,!fl!f^?°^^~^'^9"«9« referred to as t«^^ " 

n™™i are required to be used and programmed by those virtio are not highly trained 

programming environments are used. 5,e user's pro- 

optimal utilization of the computer system. wnomui 

ShZK!^^ i!f ' "^""^ mathematical steps or other prooeduras 

conceptually model a process often does not closely correspond to the traditional textLed pro- 
swmning techniques used to program a computer system to model such a process. In other words, the requirement 
« tZ^^a^^J' programming emrimnment places a level of abstraction between the user^ concep- 

^ ^"^ Implementation of a method that accomplishes this solution In a computer proffan^ 

LniTr ™ 7 ? '^T' ' ""^ '""y P"^'^^"* techniquesrprogramming a 

can be utilized to perfbmi such modeling often Is reduced. 

^^'"^IS^'* **** """P^^systems are employed to model and/or control physical systems are 
^^Jl^^'V^^- '"""^^ ™^'"^«<'"' ^"-^ ^"^"l^""- Computer mod^ing olcontrofS 
l^^lnl lllTT''- H "^^^"^ '"««««"'3'y "^^'rable In view of the 

li»«aebig <»mptolty and vanety of ^^truments and devices available for use. However, due to the wide variety of pos- 
stUelestingfcontrolsltuationsandenvlronments. and also the wide anay of instrumente or devices available, itlsc^n 

to contol such systems had to be written In conventional text-based programming languages such as fbr exampte 
assembly language. C. FORTRAN, BASIC, or Pascal Traditional usera these systwro. hcwe«r"i ITw 

tae^imurt^to ailowusera to use these languages withouttrainln^^ 
pSS S^SS. ' maintenance of the software elements In these systems often 

""^ ^'^OLSOl: and 5.301,336; among others to Kodosky et 

iS^f, "^T """''""S " P™^^' a graphical programmtag envIrann^nS* 

?3 rZriof; T^"lr' at a level above text*ased high ^ programming LSuages such ^ C. 
S=MK^ J*'"'' etal allows a user to construct a diagram using a block diagram edtor 

such that the d«gram created graphically displays a procedure or method for accomplishing a certain resuft. sucS 

JZiZ^ J! ""^ """^ "'"S^"^ * <^ata structures may be automaticalV con- 

^aractenze an executton procedure which conesponds to the displayed procedure. The graphteal pro- 
gram may be compiled or interpreted by a computer using these data structures. Therefore, a user can create a 

^™T^'^k'°''^'T """^ ' ^'^''^^"y P^<^™«"'"9 environment This graphbally based programming 
environment may be used for creating virtual instmmentation systems. Industrial autor^^n systems. modelirpT 
esses, and simulation, as well as for any type of general programming ms, mooeimg proc 

Enn, 'miT'^'J^^ f ° programming emrlronment wherein a user places or manipu- 

lates Kons In a block diagram using a btock diagram editor to create a date flow program." A graphkal program fbr co^ 
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trolling or modeling devices, such as instruments, processes or industrial automation hardware, is referred to as a 
virtual instrument (VI). In creating a virtual Instrument, a user may create a front panel or user interface panel. The front 
panel Includes various front panel objects, such as controls or indicators, that represent or display the respective input 
and output that will be used by the graphical program or VI, and may include other icons which represent devices being 
5 controlled. When the controls and indicators are created in the front panel, con^ponding icons or temninals may be 
automaficalty created in the blodc diagram by the block diagram editor. Alternatively, the user can place terminal icons 
or input^output biodcs in the blodc diagram which may later cause the display of corresponding front panel objects in the 
front panel, either at edit time or at run time. 

[0008] During creation of the graphical program, the user selects various functions that accomplish his desired 
TO result and connects the function icons together. For example, the functions may be connected In a data flow and/or con- 
trol flow format The functions m^ be connected between the terminals of the respective controls and indicators. Thus 
the user creates or assembles a data flow program, refenred to as a block diagram, representing the graphical data flow 
which accomplishes his desired function. The assembled graphical program may then be compiled or interpreited to 
produce machine language that accomplishes the desired method or process as shown in the block diagram. 
15 [0009] A user may input data to a virtual instrument using front panel controls. This Input data propagates through 
the data flow bk)ck diagram or graphical program and appears as changes on the output indicators. In an instrumenta- 
tion application, the front panel can be analogized to the front panel of an instrument. In an Industrial automation appli- 
cation the front panel can be analogized to the MMl (Man Machine Interface) of a device. The user may adjust the 
controls on the front panel to affect the input and view the output on the respective indicators. Altemativety, the front 
20 panel may be used merely to view the input and output, and the input may not be interactively manipulable by the user 
during program execution. 

[0010] Thus, graphical programming has become a powerful tool available to programmers. Graphical program- 
ming environments such as the National Instruments LabVIEW product have become very popular. Tools such as Lab- 
VI EW have greatly increased the productivity of programmers, and Increasing numbers of programmers are using 

25 graphical programming environments to develop their software applications. In particular, graphical programming tools 
are being used for test and measurement data acquisition, process control, man machine interface (MMI), supervisory 
control and data acqu^ition (SCADA) applications, simulation, and machine vision applications, among others. 
[0011] As graphical programming environments mature and grow in popularity and complexity, it becomes increas- 
ingly desirable to provide high-level tools which help a user create or edit a graphical program. It also becomes increas- 

30 ingly desirable to integrate graphical programming environments with other applications and programming 
environments. In many cases, the desired tools or the desired integration with other applications requires an ability to 
dynamically or programmatically generate or edit a graphical program or a portion of a graphical program. 
[0012] As described above, a user typically creates a gnaphical program within a graphical programming environ- 
ment by interactively or manually placing icons or nodes representing the desired blocks of functionality on a diagram, 

35 and connecting the teons/nodes together to represent the data flow of the program. The ability to programmattoally cre- 
ate^edit graphteal programs enables a graphical program to automatically be created/edited without this type of Interao- 
tlve user intervention. A system and method for programmatically creating/editing graphical programs is descrit)ed 
herein. 

40 Summary of the Invention 

[0013] One embodiment of the present invention comprises a computer-implemented system and method for pro- 
grammatically/dynamu:aliy creating or editing a graphical program. In one embodiment, a first program or client pro- 
gram is created, vtrhereln the first program specifies creation of a new graphical program. In other words, when the first 
45 program is executed, the first program Is operable to programmatically create the new graphical program. The graphical 
program may be programmatically created with little or no user input specifying the new graphical program during this 
creating. 

[0014] In various embodiments, the new graphical program that Is created may be a graphical program of any of 
various types, e.g., a graphical program created specifically so that a particular graphbal programming development 

50 environment Is operable to edit and/or execute the graphteal program. The new graphical program may Include a plu- 
rality of graphical program objects. For example, the new graphteal program may have a diagram portion including a plu- 
rality of interconnected nodes which visually Indicate functionality of the new graphical program. The new graphical 
program may also have a user interface portion including various user interface objects, such as one or more user inter- 
face panels having controls for specifying user input to the graphteal program and/or indicators for displaying output 

55 from the graphical program. 

[001 5] The first program may be a program of any of various types. For example, tfie first program may be a text- 
based program, such as a program written using C, C++, Java, Basic, or another text-based programming language. 
Also, the first program may itself be a graphical program. The first program may call an application programming inter- 
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face (API) usable for programmatically creating the new graphical program. For ©(ample, a text-based program may 
Include text-based code for calling various API functions or methods, white a graphical program may include various 
graphical nodes supported by the API. r » j 

[0016] When the first program is executed, the new graphical program is prognammatlcally created, in response to 
5 ^acuting the first program. Thus, during execution of the first program, the first program is operable to cause creation 
Of the new graphical program. As described above, the first program may specify the Inclusion of various objects in the 
nw graphical program. The first program may also specify other aspects of the graphical program, such as: intercon- 
nections between diagram objects, connections between diagram objects and user Interface objects, positions of 
objects, sizes of objects, and properties or configuration of objects (e.g.. configuration of data types, parametera etc ) 
10 among other aspects of the graphical program. /r- »k , 

[0017] In one embodiment, the first program m^ include all executable logic necessary for progrHmmatically cre- 
ating the new graphical program. However, in the praferrad embodiment, the firat program is operable to interface with 
a server program, ag., a graphical programming devetopment environment appfication, in order to request the server 
program to create the new ^phlcal program. For example, thefirst program may call a graphical program creation API 
supported by the server program. In response to receiving these API calls, the server program is executable to create 
the specified graphical program. The server program may execute on the same computer system as the firat program 
or may execute on a different computer system, e.g., a different computer system connected by a networic. 
[0018] In a related embodiment, a similar method may be used to modify an existing graphical program In other 
words. Instead of specifying creation of a new graphical program, the firat program specifies the modification of an exist- 
ing graphical program. When executed, the firat program is then operable to programmatically modify the existing 
graphical program. For example, the first program nray include a reference to the existing graphical program and may 
Inciude various API calls to modify the graphical program. e.g., by adding one or more objects to the graphical program 
Changing connections between graphical program objects, changing various properties of graphical program objects! 
eic. 
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[0019J The ability to programmatically create/edit graphical programs enables applications and tools to automati- 
cally create or modify a graphical program or a portion of a graphical program. In the preferred embodiment, any oper- 
ation which a user may perform while interactively assembling or editing a graphical program {e.g., connect two objects 
change the position of an object, change the color of an object, etc.) may be performed programmatically. 
[00201 This programmatic capability enables tools such as interactive wizards to simpfify, quicken, or automate the 
30 creation or editing of graphical programs. For example, an interactive wizard tool may present a series of user interface 
dialogs to a user, collect Information from the user, and use the collected information to dynamically generate or edit a 
con^nding graphical program. Such wizard tools may be included In a third-party application. For example, tiie 
National Instruments IMAQ Vision Builder application dynamically generates graphical programs for analyzing images 
based on user-provided information. Various ottier types of tools or applications may also create or edit graphical pro^ 

35 grams.Forexample,aprogramtranslatormaydynamteallycrBateagraphicalprogramfro^ 
as a C language program. 

Brief Description of the Drawings 

40 [00211 A better underatanding of the present invention can be obtained when tiie following detailed description of 
the preferred embodiment is considered in conjunction with the following drawings. In which: 

Rgure 1 illustrates a computer system connected through a networic to a second computer system- 
Figures 2A and 2B Ulustrate representative Instrumentation and process control systems including various I/O inter- 
ns face options; 

Rgure 3 is a biocic diagram of the computer system of Figures 1, 2A and 28; 
Figure 4 is a flowchart diagram Illustrating interactive creation or editing of a'graphlcal program- 
Figures 5A and SB illustrate a simple graphical program comprising a user interface panel and 'a block diagram- 
Rgure 6 IS a flowchart diagram illustrating one embodiment of a method for programmatically creating a graphl^ 
so program; 

Rgure 7 is a block diagram illustrating the abstract relationship between a client program, an API to prDgrammatl- 
caily create/edit a graphical program, and a server program; 

Rgure 8 illustrates an embodiment of the diem/server relationship of Rgurs 7 in which the client program is a 
graphical program, and the server program is an instance of a graphical programming environment application: 
SB Figure 9 illustrates an embodiment of the diem/server relationship of Rgure 7 in which the client program conwnu- 
nlcates wiUi the server program via an object request brol«er (ORB), and the server program is a service operable 
to create/edit a graphical program; 

Figures 10-20 illustrate graphical program nodes that may be included in a first graphical program in order to pto- 
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gmmmaticalty create or edit a second graphical program; 

Figure 21 Illustrates user interface controls which may be placed on a front panel In order to interactively obtain a 
reference to a server program or a graphicai program to edit; 

Figures 22 and 23 illustrate how a user may select graphical program objects to create or edit by choosing from 
5 hierBTchical menu^ 

Rgure 24 Illustrates a dmple client graphicai program that creates the graphical program of Rgures 5A and 5B; 
Figures ^ and 26 illustrate a slightly more complex example of a graphical program than the program of Rgures 
5A and 5B; 

Rgure 27 illustrates a graphicai program client that creates the graphical program of Rgures 25 and 26; and 
10 Rgures 28-30 Illustrate dialog boxes for configuring one embodiment of a server program. 

[0022] WhQe the invention Is susceptible to various modifications and altemative forms specific erTd)odiments are 
shown by way of example in the drawings and are herein descried in detail. It should be understood however, that 
drawings and detailed description thereto are not intended to limit the Invention to the particular form disclosed. But on 
75 the contrary the Invention is to cover all modifications, equivalents and alternative following within the spirit and scope 
of the present invention as defined by the appended claims. 

Detailed Description of the Preferred Embodiment 

20 Rgure 1 - Computer Svstem Connected to a Networic 

[0023] Rgure 1 illustrates an exemplary computer network In which a computer system 82 is connected through a 
networic 84 to a second computer system 86. The computer system 82 and the second computer system 86 can be any 
of various types, as desired. The network 84 can also be any of various types, including a LAN (local area network), 

25 WAN (wide area network), or the Internet, among others. 

[0024] The computer system 82 includes or stores a dlent computer pmgram that programmatlcally creates or 
edits a graphical program or a portion of a graphicai program. As described above, the client program may use an API 
to call a server program, such as a graphkai programming environment applteaHon, which perfomns the actual opera- 
tions of creating or editing the graphteal program. The server program may reside on the computer system 82 or on the 

30 second computer system 86. The client program may Interfiace with the server program indirectly through a proxy com- 
ponent, such as an ActiveX component The proxy component may reside on the computer system 82 or on the second 
computer system 86 or on a third computer system-connected to the network 84, 

[0025] The client, server, and proxy software programs/components may be implemented in any of various ways, 
including procedure-based techniques, component-based techniques, and/or object-oriented techniques, among oth- 
35 ens. The programs may be written using any combination of text-based or graphical programming languages. Also, the 
programs msy be written using distributed modules or components so that each of the client, server, and proxy may 
reside on any combination of computer system 82, computer system 86, and other computer systems connected to the 
network 84. 

40 Rgures 2A and 28 - instrumentation and Industrial Automation Systems 

[0026] Rgures 2A and 2B illustmte exemplary systems which may store or use ciient/serveryjDroxy programs for 
programmatlcally creating/editing graphical programs for instrumentation, process control, or other purposes. These 
programs may of course be stored in or used by other types of systems as desired. 

45 [0027] Rgure 2A illustrates an instrumentation control system 100. The system 100 comprises a host computer 
102 which connects to one or more instruments. The host computer 102 comprises a CPU, a display screen, memory, 
and one or more input devices such as a mouse or keyboard as shown. The computer 102 connects through the one 
or more instruments to analyze, measure, or control a unit under test (UUT) or process 150. The host computer 102 
may store client, server, and/or proxy computer programs or components for programmatlcally creating or editing a 

50 graphical program, such as a graphicai program which interacts with or controls the one or more instruments. In other 
words, the computer 102 may be either of computers 62 or 86. 

[0028] The one or more instruments may Include a GPIB instrument 112 and associated GP IB interface card 122, 
a data acquisition board 1 14 and associated signal conditioning circuitry 124, a VXI instrument 1 1 6, a PXI instrument 
1 1B, a video device 132 and associated image acquisitron card 134, a motion control devbe 136 and associated motion 
55 control interface card 138, and/or one or more computer based instrument cards 142, among other types of devices. 
[0029] The GPIB instrument 112 is coupled to the computer 102 via the GPIB interface card 122 provided by the 
computer 1 02. in a similar manner, the video device 1 32 is coupled to the computer 1 02 via the image acquisition caid 
134, and the motk)n control device 136 is coupled to tiie computer 102 through tiie motion control interne card 138. 
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The data acquisition board 114 is coupled to the computer 1 02. and may interface through signal conditioning circuitry 
124 to the UUT. The signal conditioning drcuftry 124 preferably comprises an SCXI (Signal Conditioning extensions for 
Instrumentation) chassis comprising one or more SCXi modules 126. 

[0030] The GPIB card 122, the image acquisition card 134, the nnotlon control interfece card 138, and the DAQ card 
1 14 are typically plugged in to an I/O slot In the connputer 102, such as a PCI bus slot, a PC Card slot, or an ISA EISA 
or MicroChannel bus slot provided by the computer loa However, these cards 122. 134, 138 and 1 14 are shown'exter- 
nal to computer 102 tor Illustrative purposes. 

[0031] The VXl chassis or instrument 11 6 is coupled to the computer 1 02 via a VXI bus. MX\ bus, or other serial or 
paranei bus provided by the computer 102. The computer 102 preferably Includes VXI interlace logic, such as a VXI 
MXI or GPIB interface card (not shown), which interfaces to the VXI chassis 1 16. The PXI chassis or instrument is pref- 
erably coupled to the computer 1 02 through the computer's PCI bus. 

[0032] A serial instrument (not shown) m^ also be coupled to the campiAer 1 02 through a serial port, such as an 
RS.232 port. USB (Unlveisai Serial bus) or IEEE 1394 or 1394.2 bus, provided by the computer 102. In typical instru- 
mentation control systems an Instrument will not be present of each Interface type, and In fact many systems may only 
have one or more Instruments of a single interlace type, such as only GPIB instruments. 

[0033] The instruments are coupled to the unit under test (UUT) or process 1 50, or are coupled to receive field sig- 
nals, typically generated by transducers. The system 1 00 may be used In a data acquisition and control appfication In 
a test and measurement application, a process control application, or a man-machine interlace application. 
[0034] Rgure 28 illustrates an exemplary industrial automation system 1 60. The industrial automation system 160 
Is similar to the instrumentation or test and measurement system 1 00 shown In Rgure 2A Elements which are similar 
or identical to elements in Rgure 2A have the same reference numerals for convenience. The system 1 60 comprises a 
computer 1 02 which connects to one or more devices or Instruments. The computer 1 02 comprises a CPU, a display 
sCTBen, memory, and one or more input devices such as a mouse or keyboard as shown. The computer 1 02 connects 
through the one or more devices to a process or device 150 to perform an automation functbn, such as MMI (Man 
iVIachine Interface), SCADA (Supervisory Control and Data Acquisition), portable or distributed data acquisition proc- 
ess control, advanced analysis, or other control. In Rgure 2B, the computer 1 02 may store client, server, and^or pmy^ 
computer programs or components for programmaficaily creating or editing a graphical program, such as a graphical 
program that is involved with the automation function performed by the automaton system 160. In other words the 
computer 102 may be either of computers 82 or 86. 

[0035] The one or more devices m^ include a data acquiation board 1 14 and associated signal conditioning cir- 
cuitry 124. a PXI instrument 118. a video device 132 and associated image acquisition card 134, a motfon control 
device 136 and associated motion control Interface card 138, a fieWbus device 170 and associated fieldbus interface 
card 1 72. a PLC (Programmable Logic Controller) 1 76, a serial Instrument 1 82 and associated serial interface card 1 84 
or a distributed data acquisition system, such as the Reldpoint system available from National instruments, amona 
othertypes of devices. 

[0036] The DAQ card 1 14, the PXI chassis 1 1 8, the video device 132. and the image acquisition card 136 are pref- 
erably connected to the computer 102 as described above. The serial Instrument 182 is coupled to the computer 102 
through a serial interface card 1 84, or through a serial port, such as an RS-232 port, provided by the computer 1 02 The 
PLC 176 couples to the computer102throughaserial port, Ethernet port, or a proprietary interface. The fieldbus inter- 
face card 172 is preferably comprised in the computer 102 and interfaces through a fieldbus networic to one or more 
fieldbus devices. Each of the DAQ card 1 14, the serial card 184, the fieldbus card 1 72, the image acquisition card 134 
and the motion control card 1 SB are typically plugged In to an I/O slot in the computer 1 02 as described above However' 
these cards 114, 184, 172, 134, and 138 are shown external to computer 102 for illustrative purposes, in typical indus- 
trial automation systems a device will not be present of each interface type, and in fact many systems m^ only have 
one or more devices of a single interface type, such as only PLCs. The devices are coupled to the device or process 
1 50. 

"-^P Refen-ing again to Figures 2A and 2B. the computer system 102 preferably includes a memory medium on 
which one or more computer programs orsoftware components according to the present invention are stored The term 
memory medium" is Intended to include an Installation medium, e.g.. a CD-ROM, floppy disks 1 04 or tape device a 
computer system memory such as DRAM. SRAM. EDO RAM. Rambus RAM, etc., or a non-volatile r^emory such a^ a 
magnetic media. e.g.. a hard drive, or optical storage. The memory medium m^ comprise othertypes of memory as 
well, or combinations thereof. ' 
[0038] In addition, the memory medium may be located in a first computer In which the programs are. executed or 
may be located In a second different computer which connects to the first computer over a network, such as the Internet 
In the latter instance, the second computer provides the program instructions to the first computer for executfon Also 
the computer system 1 02 may take various fonro, including a personal computer system, mainframe computer system' 
workstation, network appHance, Internet applfance. personal digital assistant (PDA), television system or other device' 
In general, the term "computer system" can be broadly defined to encompass any devtee having at least one processor 
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which executes Instructions from a memory medium. 

[0039] In one embodiment; the cRent program, server program, and/or the resulting graphical program that is cre- 
ated or edited are designed for data acquisition/generation, analysis, and/or display, and for controlling or modeling 
Instrumentation or Industrial automation hardware. For example, in the preferred embodiment, the server program Is the 
5 National Instruments LabVIEW graphical programming environment appfication, which provides spedatized support for 
devetopers of instrumentation E^pfications. The client program may also t>e a program Involved with Instrumentation or 
data acquisition. 

[0040] However, it is noted that the present invention can be used for a plethora of applications and is not limited to 
Instnjmentation or Industrial automation applications, in other words, Rgures 2A and 2B are exemplary only, and graph- 
10 ical programs for any of various types of purposes may be generated or edited by client^servery|?rQxy programs for any 
of various types of purposes, where the cllent/servefyproxy prrograms are stored In and execute on any of various types 
of systems. For exanq)ie, a spreadsheet program may act as a client program and may use the API descn'bed herein to 
dynamically generate a graphical program which analyzes spreadsheet data and displays the results of the analysis to 
a user. 

15 

Figure 3 - Computer System BlQd< Diagram 

[0041] Figure 3 is a block diagram of the computer system illustrated in Figures 1 , 2A and 2B. It is noted that any 
type of computer system configuration or architecture can be used as desired, and Rgure 3 Illustrates a representative 
20 PC embodiment It Is also noted that the computer system be a general purpose computer system as shown In 
Figures 2A and 2B, a computer Implemented on a VXI card installed in a VXI chassis, a computer implemented on a 
PXI card installed in a PXI chassis, or other types of embodiments. The elements of a computer not necessary to under- 
stand the present invention have been omitted for simplicity. 

[0042] The computer 102 includes at least one central processing unit or CPU 1 60 which is coupled to a processor 
25 or host bus 162. The CPU 160 may be any of various types, including an x86 processor, e.g., a Pentium dass, a Pow- 
erPC processor, a CPU from the SPARC family of RISC processors, as well as others. Main memory 1 66 Is coupled to 
the host bus 162 by means of memory controller 1 64. 

[0043] The main memory 1 66 stores computer programs according to the present invention. The main memory 1 66 
also stores operating system software as well as the software for operation of the computer system, as well known to 

30 those skilled in the art The computer programs of the present invention will be discussed In more detail below. 

[0044] The host bus 162 is coupled to an expansion or input/output bus 170 by means of a bus controller 168 or 
bus bridge logic. The expansion bus 170 is preferably the PCI (Peripheral Component Interconnect) expansion bus, 
although other bus types can be used. The expansion bus 1 70 includes slots for various devices such as the data acqui- 
sition board 1 14 (of Rgure 2A}, a GPIB interface card 122 which provides a GPIB bus interface to the GPtB instrument 

35 112 (of Figure 2A). and a VXI or MX! bus card 1 86 coupled to the VXI chassis 1 1 6 for rscehring VXI instruments. The 
computer 1 02 further comprises a video display subsystem 1 80 and hard drive 1 82 coupled to the expansion bus 1 70. 

Figures 4 - 5: Interactive Creation of a Graphical Program by a User 

40 [0045] Figure 4 is a flowchart diagram illustrating one embodiment of how a user may interactively or manually cre- 
ate or edit a graphical program. As shown in the flowchart and described below, the user manually adds various objects 
to a graphical program, connects them together, etc. In contrast, the present invention comprises a system and method 
for programmatteaily creating or editing a graphical program without requiring this type of user Interaction. 
[0046] In the embodiment shown in Rgure 4, the steps axe performed by a user creating or editing a graphical pro- 

45 gram in a graf^lcal programming environment As shown, in step 420 the user may create or edit a user Interface panel 
for displaying a graphical user interface. The user interface panel may comprise controls for accepting user input, dis- 
playing information such as program output, or both. For example, the user interface panel may Include buttons, 
selectable lists, text boxes, graph controls, images, etc. A user may "drop" various controls or other objects onto the 
user interface panel, e.g., by selecting the desired control from a control palette. Figure 5A illustrates a simple user 

50 interface panel. Step 420 is not necessarily perfomied. For example, a user interface panel may not be desired, a user 
Interface panel may be Inherently spedfled during creation of the block diagram, or a user Interface panel may automat- 
ically be created as the user creates the executable portions of the graphical program. 

[0047] A graphical program may include a block diagram comprising objects refen-ed to herein as "nodes" which are 
connected together to model the program execution logic and data flow or control flow. A block diagram node may be 
55 displayed as an icon representing the type or functionality of the node. Rgure 5B illustrates a simple block diagram. As 
a user adds objects to the user Interface panel, the graphical programming environment may automatically create a cor- 
responding object on the block diagram. Such block diagram nodes which conrespond to user Interface panel objects 
are refened to herein as user Interface nodes. For example, the Rgure 5B block diagram node labeled The result of 
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2.0 + 3.0 was:" is a user interface node corresponding to the Figure 5A user Interlace output Indicator. User interface 
nodes nray be connected with other objects or nodes in the block diagram to participate in the program logic and 
data/control flow. User interface nodes may map input/output between a user interface panel and a blodc diagram. For 
example, the user interface node in Rgure 5B receives data and displays the data In the con-esponding user interfece 
5 indicator in Rgure 5A. 

[0048] In step 422 of Rgure 4, the user adds other objects/nodes to or edits other objects/nodes of the graphical 
program. These objects or nodes may Include functton nodes which perfomi predefined functional operations such as 
numeric functions, Boolean functions, string functions, array functions, en^r functions, file functions, application control 
functions, etc. For example the block diagram shown in Rgure 5B uses an addition function node to add two constants 
w together, in step 422 the user may also add other types of nodes to the graphical program. For example, nodes may be 
added which represent numeric constants. Rgure 58 illustrates numeric constant nodes representing the floating point 
constants 2.0 and 3.0. 

[0049] Other types of nodes whfch may be added Include subprogram nodes for calling a graphical subprogram, 
global or local variable nodes for defining and using variables, etc. In step 422, the user may also add other types of 
15 objects to the graphicai program. For example, objects representing programmatic structures such as for loops, while 
loops, case structures, etc. may be added. The user may add nodes and other types of objects to a graphical program 
In various ways, e.g., by selecting a node or object from a palette that displays Icons representing the various nodes 
and objects. 

[0050] An API which enables a program to programmatically create or edit a second graphicai program is described 
20 in detail below. In one embodiment, a graphicai program may use the API by Incorporating specialized nodes to create 
or open a graphical program, add objects to or edit objects of a graphical program, etc. These specialized nodes are 
described below. 

[0051] In step 424 of Figure 4, the user connects or "wires" the graphical program objects in order to achieve the 
desired executable logic and data flow or control flow. For example the objects may include input and output terminals, 

25 and the user may connect the output temninal of one node to the Input terminal of another node, etc. Figure 58 illus- 
trates one embodiment of how objects may be connected. In this example, output terminals of the two numeric constant 
riodes are connected to the Input terminals of an addition function node. The addition function node performs the addi- 
tion operation on the numeric input The output terminal of the addition function node is connected to the input of the 
user interface Indicator node so that the result of the addition operation Is displayed In the user Interface panel shown 

30 In Rgure 5A. 

IP052] Programmatic structure objects may also Include tennlnals which integrate them with the other objects of the 
graphical program. For example, a while loop may comprise a condition terminal to which an output terminal of a node 
supplying a boolean value may be connected to signify when the loop should end. 

[0053] In step 426 of Rgure 4, the user saves or runs the graphical program. Tlie graphical program may be saved 
35 in any of various formats. For example, a tree of data stmctures n^y be built which represents the various elements of 
the graphical program and the relationships among the elements, and the data stnjctures m^ be saved In a binaiy or 
text format. If the graphicai program includes user interface panels, these panels may also be saved. In step 426 the 
user may also execute the graphical program. The user may run the graphical program in any of various ways. For 
example, a graphbal programming environment may allow a program to be run from within the development environ- 
40 ment, or the user may create a standalone program and run the program, etc. 

[0054] It is noted that steps 420 through 426 typically occur In an iterative manner and typically occur in various 
orders. For example a user may add a user interface control to a user interface panel, then connect a user interface 
node con^pondlng to the control to another node, then add and connect a function node to the program, then run ttie 
program to test it. tiien change the way a node is connected, etc. Thus, the flowchart of Rgure 4 is exemplary, and var- 
45 ious steps may be combined, omitted, added, or modified as required or desired for developing different graphical pro- 
grams or using different embodiments of graphical program development environments. 

[0055] Also, Rgure 4 illustrates one embodiment of how a user may create/edit a graphical program, and the proc- 
ess may differ for otiier embodiments. As described above, a client program, which may be a graphical program, may 
interfece with a server program, directly or through a proxy program or component, in order to pragrBmmatically create 

so or edit a graphical program. The server program may be a graphical programming environment operable to respond to 
the client program's requests for creating/editing the graphical program. In the prefen-ed embodiment, the graphical pro- 
gramming environment is ttie LabVIEW graphical programming environment available from National Instruments. For 
more infomiation on the l_abVIEW graphical programming environment and its abilities to create graphical programs 
and convnunicate wltti client programs, please refer to the LabVIEW system documentation available from National 

55 Instruments, as well as the patent applications incorporated by reference above. 
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Raure 6 - Programmatic Creation of a Graphical Program 

[0056] Rgure 6 is a flowchart diagram illustrating one embodiment of a method for programmatically creating a 
graphicai program, in step 450, a first program is created, wherein the first program specifies creation of a new graph- 

5 ical program. In other words, when the first program is executed, the first program Is operable to programmaficaily cre- 
ate the new graphical program. The graphical program may be programmatically created with little or no user input 
specifying the new graphical program during this creating. In one embodiment, the graphical program is programmati- 
cally created with no user input required. In another embodiment, the user may be prompted for certain dedsions during 
progranvnatic creation, such as the type of graphical program, the \ook and feel of the user interface in the graphical 

10 program, the number or degree of comments contained within the graphical program, etc. 

[0057] in various embodiments, the new graphicai program that is created may be a graphical program of any of 
various types, e.g., a g^hicai program created specifically so that a particular graphical programming development 
environment is operable to edit and/or execute the graphicai program. The new graphical program may include a plu- 
rality of graphical program objects. For example, the new graphical program may have a diagram portion including a plu* 

IS rality of interconnected nodes which visually Indicate functionality of the new graphical program. The new graphical 
program may also have a user interface portion Including various user interface objects, such as one or more user inter- 
face panels having controls for spectfytng user Input to the graphical program and/or indicators for displaying output 
from the graphical program. 

[0058] The first program that is created in step 450 may be a program of any of various types. For example, the first 
20 program may be a text-based program, such as a program written using C, Oh-. Java. Basic, or another text-based pro- 
granrvTiing language. Also, the first program may itsetf be a graphical program. For example, the first program may be a 
program interactively created by a user, e.g., as described above with reference to Rgures 5A and SB. As described 
below, the first program may call an application programming Interiace (API) usable for programmatically creating tiie 
new graphical program. For example, a text-based program may include text-based code for calling various API func- 
25 tions or methods, while a graphical program may include various graphicai nodes supported by the API. 
[0059] In step 452. the first program is executed. 

[0060] in step 454, the new graphical program is programmatically created, in response to executing the first pro- 
gram. Thus, during execution of the first program, the first program is operable to cause creation of the new graphical 
program. As described above, the first program may specify the inclusion of various objects in the new graphical pro- 
30 gram. The first program may also specify other aspects of tiie graphical program, such as: interconnections between 
diagram objects, connections between diagram objects and user interface objects, positions of objects, sizes of objects, 
and properties or configuration of objects (e.g., configuration of data types, parametere, eta), among other aspects of 
the graphical program. 

[0061] In one ennbodiment. the first program may include all executable logic necessary for programmatically cre- 
35 ating the new graphical program. However, in the preferred embodiment, the first program is operable to interface with 
a server program, e.g., a graphical programming development environment application, in order to request the server 
program to create the new graphical program. For example, the first program, may call a graphical program creation API 
supported by the server program. In response to receiving these API calls, the server program is executable to create 
the specified graphical program. The server program may execute on tiie same computer system as the first program 
40 or may execute on a different computer system, e.g., a different computer system connected by a networlt 

[0062] The method of Figure 6 is illustrated and is described above in terms of creating a new graphicai program, 
it is noted that a similar method may be used to modify an existing graphical program. In other words. Instead of spec- 
ifying creation of a new graphicai program, the first program specifies the modification of an existing graphical program. 
When executed, the first program is tiien operable to programmatically modify the existing graphical program. For 
45 example, the first program may include a reference to the existing graphical program and may include various API calls 
to modify the graphical program, e.g., by adding one or more objects to tiie graphical program, changing connections 
between graphicai program objects, changing various properties of graphical program objects, etc. 

Raure 7 - Client Program Accesses Server Program Through an API 

SO 

[0083] Rgure 7 is a block diagram illustrating the abstract relationship between a client program 502 (e.g.. the first 
program illustrated in Rgure 6). an API 504 to programmatically create/edit a graphical program, and a server program 
506. As noted above, tfie client program 502 may be any of various types of programs. For example, the client program 
502 may be a graphical program. The client program 502 may also be a text-based program such as a C-h- program, a 
55 Visual Basic program, a Java program, etc., or any combination of these or other languages. The client program 502 
may execute independentiy or may execute within an execution subsystem of an application development environment 
[0064] The client program 502 may call tiie API 504 in any of various ways. For example, a client graphical program 
may include graphical nodes con^esponding to the API 504. One embodiment of a set of graphical nodes which a client 
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graphical program may utilize to create/edit a graphical program is described in detail below. A client graphical program 
r^.l^.?,^"*®"^^ ""^^ text-based code which calls the API 504. For example, the dient graphical program may be a 
LabvlEW graphical program which includes code Interface node& 

[0065] The client program 502 may call the API 504 In various other For example, the server program 606 
niay expose a component such as an ActiveX component. CORBA component, JavaBeans component, etc., and the 
client program 502 may obtain a reference to the object to Invoke functions or methods of the API 504. The API 604 
may also be integrated with the language or development environment of the client program 502, e.g., as a library 
[G06q Through the API 504, the client program 502 communicates with a server program 506. The server program 
506 is operable to perfonn the actions indicated by the API. For example, the server program may be operable to create 
a new graphical program, add objects to the graphical program, connect graphical program objects, etc. The server pro- 
gram 506 IS preferably an instance of a graphical programming environment In the preferred embodiment, the server 
program 506 Is an instance of the LabVIEW graphical programming environment 

[0067] Rgure 7 illustrates the abstract relationship between the client program 502, the API 504, and the server 
program 506. In actual embodiments, various layers may exist which Implement the elements of the Rgure 7 relation- 
ship. For exanr^le. the client program 502 may be a part of a larger software application, the server program 508 may 
receive Information sent by the client program via an intermediate server, etc. 

Fmr^ 9 - Client Graphical Program Accesses Gmphl« a | Programming Environmgnt 

[0068] Rgure 8 illustrates one embodiment of the client/server relationship of Rgure 7. In the embodiment of Figure 
8, the client program 502 is a graphical program, and the server program 506 is an instance of a graphical programming 
environment application. The cOent graphical program 502 may execute Independently or may execute within an exe- 
cution subsystem 510. such as an execution subsystem of a graphical programming environment The client graphical 
program 602 may be a graphical program created using the same graphical programming environment as the graphical 
programming environment sewer 506. For exanple, tiie client graphical program 502 may be a LabVIEW graphical pro- 
gram, and the server program 506 may be a LabVIEW application. 

[0069] Ihe client graphical program 502 utilizes the API 504 of Rgure 7 to communicate with the graphical pro- 
gramming environment server 506. For example, the client graphical program 502 m^ include a graphical node which 
requests the graphical programming environment 506 to open an existing graphical program, one or more modify nodes 
which request the graphical programming environment to modHy the graphical program, e.g., by modifying properties 
of graphical program objects, etc. ^ »r r 

[007fl -me functionality of the API 504 may be Implemented In various ways. In the example of Rgure 8, the client 
graphical program 512 interfaces with a runtime library 514 which includes code corresponding to ttie API nodes In 
other embodiments, the graphical program may interface with othertypes of software components which implement the 
API, such as ActiveX. CORBA, or JavaBeans components. 

[0071] The client graphical program 502 may execute in a different location than ttie graphical programming envi- 
ronment server 506. The client and server programs may communicate using any of various types of protocols such 
as the TCP/IP network protocol. As shown In Rgure 8. the runtime library 514 m^ Include TCP/IP client code 51 6 and 
the graphical programming environment sender 506 may Include TCP/IP server code 51 8. The TCP/iP server code 51 8 
may listen for requests from TCP/IP client code 516. Once a connection is established, the client code 516 and server 
code 518 may exchange messages using a message protocol. 

[0072] The block diagram of Figure 8 illustrates an architecture In which the client program 502 communicates with 
a server program 506 via a defined protocol. Thus, both tt^e client program and the server program must know the 
required communications protocol. In the preferred embodiment of Figure 8. the client graphfcal program 502 Is a Lab- 
w f!! 9f P'^'^^' P^'S'^^' and the server program 506 is a LabVIEW application Instance, In tills errrtwdiment, the Lab- 
. uw^r-'ixf"^ ^'^^'^ '"^'"^^ ^"^^ ^ described below, for communicating with the 

LabVIEW application server and causing the LabVIEW application serverto create/etfit a graphteal program. 

Rgure 9 > ORB Client Pro gram Accesses Graphical Program Seiyi^ a 

[0073] Rgure 9 illustrates an embodiment of the client/server relationship of Figure 7. in whteh a client program 502 
may communteatewithaserver program 506 without needing to useaprotocol specific to the dient orsen^^^ 
In the embodiment shown in Figure 9. the client program 502 is a program which communicates with the server pro- 
gram 506 via an object request broker (ORB), and the server program 506 is a service operable to create/edit a graph- 
ical program, refemed to as a graphical program service. The client program 502 may be a text-based program such as 
a Visual Basic, C++, Java. etc. program, or may be a graphteal program. The graphical program servfee 506 may be 
implemented In any of various ways. For example, the service 506 m^ encapsulate or call a portion of a graphteai pro- 
gramming environment which is operable to create/edit a graphical program, or alternatively, the servfce 506 may be a 
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standalone program operable to create/ecTit a graphical program. 

[0074] Figure 9 Illustrates the general relationship in which a client program references a service object via an ORB. 
The ORB may be any of various ORBs, such as the ActiveX/DCOM system, a CORBA system, a Java application envi- 
ronment, etc. The cOent program 502 requests a reference to the graphical program service 506 from the ORB 534. The 

s ORB may create a proxy stub 532 for the client program 502 and a server stub 536 for the graphical program service. 
As shovtm in Figure 9, the proxy stub 532 communteate through the ORB infrastructure 534 with the server stub 
536, and the server stub 536 may interface with the graphical program service 506. The proxy stub 532 may comprise 
API functions/methods to create/edit a graphical program which the client program 502 may invoke, and the ORB may 
transparently cause the graphical program service 506 to execute the coniesponding functions/methods. 

10 [0075] As an example, the ORB 532 may be the ActlveX/DCOM system, the client program 602 may be an auto- 
mation client program, such as a Visual Basic automation client, and the graphical program service 506 m^ be an 
ActiveX component provided by a graphical programming environment. In this example, the client program 502 may 
create a reference to the Acth/eX graphical program ser^noe component in the standard w£^ and may invoice methods 
on the component to create/edit a graphical program. The ActiveX component may then execute appropriate portions 

15 of the graphical programming environment code in order to perform the requested operations. As another example, the 
ORB may be a Java application environment, and the client program 502 and the graphical program service 506 may 
be Java programs. In this example, the client program 502 may request an interface to the graphical program 506 and 
may use the interface to request the graphical program service 506 to create/edit a graphical program. 
[0076] The block diagram of Rgure 9 Illustrates a general architecture In which the client program 502 communi- 

20 cates with a graphical program service 506 via intermediate software proxies or components. Various elements of Rg- 
ure 9 may not be present, or various other elements may also be present, as appropriate for particular embodiments. 
In the prefen-ed embodiment, the graphical program service is a software component such as an ActiveX component 
which is provWed by the LabVlEW graphical programming environment for client programs to use to programmatically 
create/edit graphical programs. 

25 

Roures 1 0 - 23: Vi Server Functions 

[0077] The server program 506 of Rgure 7 is operable to receive requests to create/edit a graphical program from 
a client and perform the actual operations of creating/editing the graphteai program. In the preferred embodiment, tiie 

30 server program of Rgure 7 is an application Instance of the LabVIEW graphical programming environment As noted 
above, the LabVIEW environment provides specialized support for developers of Instrumentation and industrial auto- 
mation applteations, and a LabVIEW graphical program may be referred to as a virtual instrument or VI. The LabVIEW 
environment comprises functionality refen-ed to as "VI Server" which enables client programs to communicate with the 
LabVIEW environment The VI Server functionality enables dient programs to create or edit a I^ViEW graphical pro- 

3S gram or VI. 

[0078] A client program which requests LabVIEW to create/edit a VI may itself be a VI. A client VI may include par- 
ticular nodes in tiie VI which utilize the VI Server functionality of a LabVIEW instance to request the LabVIEW instance 
to create a new VI, add objects to the VI, etc. These nodes are described in Figures 10-23 below, and Rgures 24-27 
illustrate exemplary uses of these nodes. LabVIEW also provides components such as ActiveX components which ena- 
40 ble text-based programs such as Visual Basic programs, Visual C++ programs, etc. to access the VI Server functional- 
ity. In the prefen-ed embodiment, these components enable text-based programs to perfomi all of the functions 
described below. 

[0079] It is noted that, altiiough ttie implementations of the blocks shown In Rgure 7 are descrbed with reference 
to the preferred embodiment of LabVIEW and VI Server, these Implementations may differ in other embodiments. 

45 

Rgure 10 > Open Application Reference Node 

[0080] Rgure 1 0 illustrates the Open Application Reference node. The Open Application Reference node returns a 
reference to a VI Server application running on the specified computer. If an empty string is specified for machine 
50 name, then the node returns a reference to the local LabVI EW applk^ation in which this function is running. If a machine 
name is specified, tiien tiie node attempts to establi^ a TCP connection with a remote VI Server on that machine on 
the specified port 

[0081] The application reference output can be used as an input to the Property and Invoke nodes described 
below to get or set properties and invoke methods on the application. The application reference output is used as the 
55 input to ttie Open VI Reference function to obtain references to Vis in that application. The reference is closed with the 
Close Application or VI Reference function. If the user forgets to close this refeiBnce, the reference closes automatically 
when tile top level VI associated witii this function finishes executing. However, closing tiie reference operates to con- 
serve the resources Involved in maintaining the connection. 
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[0082] The following describes the Inputs and outputs of the Open Application Reference node: 

machine name is the address of the computer that runs a copy of LabVIEW to which it is desired to estabRsh a 
connection, "mis address can be In dotted decimal notation (such as 130.164.15.250) or domain name notation 
(such as foo.natlnstcom). An empty string will cause this function to retum a reference to the local LabVIEW. The 
machine name input enables cRent programs to communicate with a VI Server Instance running on any computer 
connected to the Intern^. 

port number is the port on which the remote LabVIEW application Is listening. If port number Is not wired, the 
default VI Server listener port number (e.g., 3363) is used. 

error in describes en-or conditions that occur prior to the execution of this function. The default Input of this cluster 
Is "no em)r". If the error Boolean of this cluster Is True, the Open Application Reference function wni do nothing but 
pass through the en'or via the error out output 
appllcaUon reference Is the reference to the specified application. 

error out contains error Infomiatlon. If error In Indicates an enor, enor out contains the same error infomiation 
Otherwise it describes the error status that this function produces. 

Figure 11 ■ Open VI Refer^ncfl Mn^ 

[0083] Rgure 1 1 illustrates the Open VI Reference node. The Open VI Reference node returns a reference to a VI 
specified by a name string or path to the Vi's location on disk. This reference may then be used to edit the VI In the 
current embodiment, references can only be obtained to standard Vis. This excludes Control, Typedef, and Global Vis. 
In the preferred embodiment, the Open VI Reference node can be used to obtain a reference to any VI. 
[0084] References to Vis In another LabVIEW application are obtained by wiring an application reference 
(obtained from the Open Application Reference function) to this function. In this case, the path Input refers to the file 
system on the remote LabVIEW computer. If a reference to the local LabVIEW application is wired the same behavior 
Is obtained as if nothing had been wired to the application reference Input 

[0085] If editing operations are to be perfonned on the referenced VI, and the VI has a passwoitl-protected dia- 
gram, the password is provided to the password string Input If the incorrect password is provided, the Open VI Refer- 
ence function returns an error and an invalid VI reference. If no password Is provided when opening a reference to a VI 
that IS password protected, the reference can stilt be obtained, operations can only be performed that do not edit the VI 
[0086] If the specified VI Is to be called through the Call By Reference function, a strictly-typed VI reference is wired 
to the type specifier Input. The function Ignores the value of this Input. Only the Inpuf s type - the connector pane Infor- 
nrtation - is used. By specifying this type, the Open VI Reference function verifies at run tune that the referenced Vlte 
connector pane matches that of the type specifier input 

[0087] If a Generic VI refnum type is wired to the type specifier input, this results In the same behavior as rf the tvoe 
specifier Input had not been wired at all. 

[0088] If the type specifier input Is wired with a stridly-typed VI refnum, the VI must meet several requirements 
before the VI reference is retumed successfully: 

1) The VI cannot be breken for any reason. 

2) The VI must be runnabfe as a subVI, that Is, it cannot be active as a top-level VI (unless the VI is re-entrant) 

3) The connector pane of the VI must match that of the type specifier. 

[0089] If the user forgets to close this reference using a close reference node, the reference closes automatically 
when the top-level Vi associated with this function finishes executing. However, closing the reference operHles to con- 
serve the resources Involved In maintaining the connection. 

[0090] If a strictly-typed reference to a reentrant VI Is obtained, a dedicated data space is allocated for that refer- 
ence. This data space is preferably always used and is used only In conjunction with the output VI reference This can 
lead to some new behavlore In LabVIEW. For example, parallel calls (using the Call By Reference node) to a reentrant 
VI using the same VI reference do not execute In parallel, but executes serially, one after the other. As another example 
a reentrant VI could get a reference to itself (allocating a new data space) and call itself recursively through the Call By 
Reference node. It is noted that allocating a data space dynamically is both time consuming and memory consuming 
and Is not generally recommended for implementing recursive algorithms. 

[0091] A VI reference Is similar to what is known as a function pointer in other languages. However, in LabVIEW 

these function pointers also can be used to reference Vis across a networit 

[0092] The following describes the inputs and outputs of the Open VI Reference node: 

appncaUon reference is a reference to a LabVIEW appilcatton. If this input is left unwired, the reference s to an 
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applicatton on the local version of LabVIEW. If the input is wired, and the reference Is to a remote version of Lab- 
VIEW, then the remote LabVIEW is queried to return the VI reference. 

type specifier Is used for Its data type only. The value of the input is ignored. The data type of the type specifier 
input detemfilnes the data type of the vl reference output VI name or path is polymorphic and can accept a string 
5 containing the name of the desired VI, or a path containing the complete path (including the name) to the desired 
VI. If a name string Is wired, then the VI must already be in memory. If a path is wired and the VI Is already In menv 
ory, the VI in memory is obtained, whether Hb path is the same as the Input or not If the Vi Is not in memory, then 
the VI must be at the specified path for this function to succeed. If the VI is at that location, the VI Is loaded into 
memory. 

10 error in describes error conditions that occur prior to the execution of this function. The default input of this cluster 
is no em>r. 

password is the plain-text password string for the VI. If the VI is not password protected, the Input is ignored. If the 
VI is password protected and an inconrect password is entered, the Vi can be referenced, but the VI cannot be 
edited through that VI reference. 
1$ vl reference Is the refnum associated with the requested VI. If the function fails, "not-a-refnum" is returned. 

error out contains error infonnation. If error In Indicates an en-or. error out contains the same error infonnation. 
Otherwise error out describes the error status that this VI produces. 

[0093] if th e user specifies a remote version of LabVI EW by the application reference input, the path is interpreted 
20 on the remote machine in the context of the remote file system. The path is expressed using the local computer's path 
, separators, but Is translated to the remote computer's path separators when the request anives there. For example, to 
reference a VI on a Madntosh at MyHD:LabVIEW Vls,1do.vi from a Windows application, the Window's path syntax: 
MyHD:\LabVIEW Wsl/baW would be used. Conversely, to reference a VI on a Windows computer at C:\labview\^.vi 
from a Macintosh application, the Macintosh path syntax: Ciativiewido.}^ would be used. 

2S 

Figure 1g - New VI Reference Node 

[0094] Rgure 1 2 illustrates the New VI Reference node. The New VI Reference node creates a new VI and outputs 
a reference to the new VI. The following describes the inputs and outputs of the New VI Reference node: 

30 

application reference is an Input reference to a local or remote LabVIEW application. Such a reference may be 
obtained from the Open Application Reference node. If this input is left unwired, the reference is to an application 
on the local version of LabVIEW. 

template is a path of or reference to an existing VI to be used as a template for the new VI. If the template input is 
35 wired, the new Vt will be a copy of the template VI. 

vl type specifies the type of Vi to create. The possible types are: standard VI, global VI, or control VI. 

error In describes en-or conditions that occur prior to the execution of this function. The default input of this cluster 

Is no en-or. 

password Is the password input for the template VI, if a password-protected VI Is wired to the template input. If the 
40 template VI is not passwonj protected, the password input Is ignored. 

vl reference Is the refnum associated with the newly created VI. If the function fails, •not-a-refnum" is returned, 
error out contains error information. If error In indicates an enor, error out contains the same error infbnmation. 
Othenvise error out describes the enor status that this node produces. 

45 Rgure 13 - Open VI Object Reference Npde 

[0095] Rgure 13 illustrates the Open VI Object Reference node. The Open VI Object Reference node outputs a ref- 
erence to an object contained in a VI. The following describes the Inputs and outputs of the Open VI Object Reference 
node: 

50 

vi object dass specifies the type of object reference to obtain. References to both objects of a front panel (user 
interface panel) and of a block diagram may be obtained. Rgure 22 illustrates how a user msy choose a value for 
the vl object class input by selecting from a hierarchical menu. i=br example, a "slide" value may be chosen to des- 
ignate that the reference to obtain is a reference to a slide user interface control. 
55 owner reference is an Input reference to the object that "owns* or "contains" the object for which a reference is to 
be obtained. The owner reference may be a reference to a VI or to an object within a VI. For example, the owner 
reference may be a reference to a block diagram node, and the reference to be otitained may be a reference to an 
Input terminal of the block diagram node. 



13 



10 



15 



2S 



30 



40 



45 



50 



EP1077404 A2 

name/order Identifies the name or order, e.g. zplane order, of the (^Ject for which to obtain a reference The 
name/order Input may be a simple string, an anBy of strings, or a numeric constant An arr^ of names may be used 
If the object Is a nested object. For example, to access the status boolean of an error cluster in an anay called 
■myArray", the name amay may be: rmyAmay", NULL, "status"]. 

error In describes en^r conditions that occur prior to the execution of this function. The default input of this cluster 
is no error. 

objecl reference is an output reference to the object specified by the node inputs. If the function falls, "not-a-ref- 
num" is returned. 

error out contains error Infomiatlon. If error In Indicates an error, error out contains the same enx>r information 
Othennrfse error out describes the enor status that this node produces. 

Rqure 14 - New VI Qb|Bct Ra ference Noda 

[00961 Rpure 14 tiiustrates the New VI Object Reference node. The New VI Object Reference node creates a new 
VI object and outputs a reference to the new VI object The following dascr&)es the Inputs and outputs of the New Vt 
Object Reference node: 

auto wire Is a boolean Input specifying whether to automatically wire the terminals of the new object with compat- 
ible terminals of a source object. This Input is only applicable for diagram objecte, not user Interface objects If this 
input is wired, then the position/next to input should also be wired. 

vi object dass specifies the type of object to create. Both objecte for a front panel (user interface paneO and for a 
block diagram may be created Rgure 22 Illustrates how a user may choose a value for the vi object class input 
by seizing from a hlerarchicai menu. For example, a "slide" value may be chosen to designate that the reference 
to obtain Is a reference to a slide user interiiace control. 

owner reference Is a reference to the VI or VI object that will 'own" or "contain" the new object. For example the 
owner may be the VI, and the new object may be a new function node to add 

style specifies the style or sub-class of object to create. Figure 23 illustrates how a user may choose a value for 
the style Input by selecting from a hierarchical menu. For example, If "slide" Is chosen as the vl object class input 
then Vertical pointer slide" m^ be chosen for the style input The style input is Ignored if the path input Is wired ' 
positioit^ext to specifies a position for the new objecl. An X-Y coordinate pair may be wired to this input, or a ref- 
erence to an existing object may be wired If an object reference is wired In, then the new object is positioned next 
to the referenced object 

error In describes en-or conditions that occur prior to the execution of this function. The default input of this cluster 
is no error. 

path specifies the location of a user control/VI. 

bounds specifies the size of the new object The bounds input is Ignored for fixed^ize objects. 
Rqure 15 - Upcast ReferennA KInrip 

P°^^u, J^^tl[® '""^^ *® ^P"^ Reference node. The Upcast Reference node casts the type of a reference 
to an objecl to the type of a superclass for the object The following describes the Inputs and outputs of the Upcast Ref- 
erence node: 

vi object reference specifies a VI object reference to upcast, 

vi object dass specifies a class to cast the object reference to. Rgure 22 illustrates how a user may choose an 
object class from a hierarchical menu. For example a reference to a vertical pointer slide object may be upcasted 
to a reference to a general slide object 

upcasted reference is an output reference with the specified class as the reference type information: If the upcast 
fails, "not-a-refnum" is the output value. 



Figure 16 - DowriM^ Rfff**«rr? N^^? 

[009S] Rgure 1 6 Illustrates the Downcast Reference node. The Downcast Reference node caste the type of a ref- 
erence to an object to the type of a subclass. The following describes the Inputs and outputs of the Downcast Reference 
55 node: 

vl object reference specifies a Vi object reference to downcast 

vi object class specifies a dass to cast the object reference to. Rgure 23 Illustrates howa user may cto^^ 
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from a hierarchical menu. For exarpple a reference to a general slide object n:iay be downcasted to a reference to 
a vertical pointer slide object 

error In describes bttot conditions that occur prior to the execution of this function. Tlie default input of this cluster 
is no error. 

5 downcasted reference is an output reference with the specified class as the reference type information. If the 
downcast fails, "not-a-refnum" is the output value. 

error out contains error information. If error In indicates an error, error out contains the same error Infonmation. 
Otherwise error out describes the error status that this node produces. 

10 Haure 1 7 - Close Application or VI Reference Node 

[0099] Rgure 17 illustrates the Close Appfication or Vi Reference node. The Close Application or VI Reference 
riode closes an open VI or the connection to a LabVIEW application instance. The following describes the inputs and 
outputs of the Close Application or VI Reference node: 

IS 

application or vi reference is the refnum associated with an open VI or a LabVIEW appfication instance. 

error In describes emor conditions that occur prior to the execution of this function. The defeult Input of this cluster 

is no encr. 

error out contains ent)r information. If en-or in indicates an enor, enor out contains the same en^r Information. 
20 OthenAfise it describes the error status that this node produces. 

Rgure 18 - Call By Reference Node 

[0100] Figure 1 8 Illustrates the Call By Reference node. The Call By Reference node may be used to call a VI, such 

25 as a VI which has been created programmatically The Call By Reference node is similar to a sub-VI node In that either 
can be used to call a VI. However, a sub-VI node Is statically linked to a particular VI that the user determines when 
he/she drops the node on the diagram. With the Call By Reference node, the VI that is called is detenmined dynamically 
at mn lime by the value of the VI reference wired to the reference input at the top of the node. Thus, the Vi which is 
called by the Call By Reference node may be on a different computer. 

30 [0101] The top of the Call By Reference node includes four terminals: an input/output pair of flow through VI refer- 
ence temiinals, and an input/output pair of flow through error clusters. The VI reference input accepts wires only from 
strictly-typed VI references. Below these terminals Is an area within which a connector pane resides (is displayed) that 
is identical to that of a VI with its terminals showing (rather than its icon). The connector pane of the strictly-typed VI 
reference input detemnines the pattern and data types of this connector pane which Is displayed in the Call By Refer- 

35 ence node icon. The user wires to these terminals Just as he/she would to a nomial sub-VI. 

[0102] As long as none of the temninals of the connector pane have wires attached to them, the connector pane will 
adapt automatically to that of the input VI reference's connector pane. However, if any of them are wired, the node does 
not adapt automatically, and the user must explicitly change the connector pane (possibly breaking those wires) by pop- 
ping up on the node and selecting the Adapt To Reference Input menu item. 

40 [0103] At run time there is a small amount of overhead In calling the VI that is not necessary in a normal sub-VI call. 
This overhead comes from validating the VI reference and a few other bookkeeping details. However, for a call to a VI 
in the local LabVI EW, this overhead should be insignificant for all but the smallest subVts. Calling a VI located in another 
LabVIEW application (across the network) may Involve more overhead. 
[0104] The following describes the Inputs and outputs of the Call By Reference node: 

45 

vl reference is the refnum associated with a Vi that is already open. 

error In describes en^r conditions that occur prior to the execution of this function. The default input of this cluster 
is no en'or. 

dup reference has the same value as reference. 
so error out contains em)r infomiation. If error In indicates an effor, error out contains the same error infomiation. 
Otherwise, it describes the error status that this VI produces. 

Rgure 19 - Property Node 

55 [0105] Rgure 1 9 illustrates the Property node. The Property node sets (writes) or gets (reads) application, VI and 
VI object property information. Thus, the Property node may be used to create/edit a graphfcal program. For ecample, 
the property node may be used to change the color of a user intertace object, etc. 

[0106] To select a specific property, the user pop ups on one of the name tenninais and selects Properties. The 
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list of available properties to select from may depend on the type of object wired to the reference input To set property 
information, the user pop ups and selects Change to Write. To get property information the user pop ups and selects 
Change to Read. Some properties are read only, so Change to Write cannot be seen In the popup menu. If the user 
desires to add items to the node, the user pop ups and selects Add Bement or clicks and drags the node to expand 

5 the number of Items In the node. The properties are changed in the order from top to bottom, if an error occurs on one 
of the properties, the node stops at that property and returns an error In this case, no further properties are handled. 
The error string reports which property caused the error If the small direction arrow on a properly Is on the left, then 
the property value Is being set If the small direction an'ow on the property is on the right, the user is getting the property 
value. Each property name has a short or long name which can be changed by popping up and selecting Name For- 

10 mat. Another name format is no name where only the type Is displayed for each property. 

The Property node may be used to access or affect a number of different properties, including VI (virtual Instrument) 
and application properties. 

[0107] The Inputs and outputs of the Property node are described below. 

IS reference is the refnum associated with a VI object, VI, or a LabVIEW application Instance. 

error in describes en'or conditions that occur prior to the execution of this function. The default Input of this cluster 
is no error. 

dup reference has the same value as reference. 

error out contains error infonnation. If error In indicates an en-or, error out contains tiie same error Information. 
20 Otiierwise error out describes tiie error status that this node produces. 

Rgura2Q-invokfiNlQde 

[0108] Rgure 20 illustrates the Invoke node. The Invoke node Invokes a method or action on a VI or VI object Thus, 
25 the Invoke node may be used to create/edit a graphical program. For example, a method may be invoked on a block 
diagram node to reposition the node, wire the node to another node, etc. Most methods have parameters associated 
with them. To select the method, tiie user pops up anywhere on the node and select Methods. Once the user selects 
the nnethod, the associated parameters appear In the node, as shown in Figure 20. The number of parameters shown 
may vary, depending on which method is selected. Each parameter may have an Input terminal, output temnlnal, or 
30 both. An output terminal may be present for the return value of the method. The Invoke node ms^ be used to Invoke a 
number of different methods, including VI (virtual instrument), VI object, and application methods. 
[0109] The inputs and outputs of the Invoke node are as follows: 

reference is the refnum associated with a VI object, Vi, or application on which the user desires to perform an 
3S action. 

error In describes error conditions that occur prior to the execution of this function. The default input of this duster 
Is no enor 

dup reference has the same value as reference. 

error out contains error information. If error in indicates an enx}r, error out contains the same en'or information. 
40 Otiierwise error out describes the error status that this node produces. 

Figure 21 - Vi Server Refnum Controls 

[0110] Figure 21 illustrates user interface controls which may be placed on a front panel in orderto interactively 
45 obtedn a reference, such as a reference to a VI or an object of a VI. Figure 21 illustrates exemplary front panel refnum 
controls for Application, Generic VI. and Strlctiy^yped VI datatypes. It is noted however, tiiat a graphical programming 
system may provide such front panel refnum controls for any of the various objects associated with a Vi, Including ter- 
minals, etc. As shown in Rgure 21 , the image In each refnum con indicates the type of the refnum. 
[0111] As shown in Rgure 21 , VI references may be sul>divided into two classes of Vis: the Generic VI and the 
50 Stnctiy typed VI. In general, a Generic VI reference is used to perform editing operations (e.g., setting properties or 
invoking functions) on any VI, and a Strictly-typed VI reference is used to call a dynamically loaded VI as a sub-VI. and 
to perfbnm operations that do not edit or change the VI. The Application class refnum icon displays the LabVIEW appli- 
cation icon. The Generic VI dass refnum icon displays the VI file icon. The Strictly-typed Vt class refnum icon depicts 
the connector pane that defines the dass. 
55 [01 12] A front panel refnum provides a reference to an appropriate entity. Thus, the Application refnum provides a 
reference to a graphical programming application, e.g. a LabVIEW application, the generic VI refnum provides a refer- 
ence to a generic virtual instrument or generic graphical program, and the strtetly typed VI refnum provides a reference 
to a specified graphical program or VI. Other types of refnums provide references to their con-esponding graphical pro- 
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Qram objects. 

[01 1 3] In the preferred embodiment, the user selects a VI Server front panel refnum control and places this ref num 
control In a front panel of a VI. The user then configures the refnum to be an appropriate type, such as an Application 
refnum, a Generic VI refnum, a Strictly-typed VI r^m, or another type of refnum. Once the user has configured the 

5 refnum control to the appropriate type, the refnum control takes on the respective appearance by the class selected by 
the user. For example, If the user drops the front pane! refnum control on the front panel and configures the refnum to 
• be of the Application dass, the refnum takes on the Appllc^ion icon appearance shown In Figure 21. 
[0114] When the user drops or places the VI Sender refnum in the front panel and configures the refnum, corre- 
sponding terminals appear in the block diagram. These terminals provide the infonmatlon on the application or graphical 

10 program referenced by the refnum. 

Figure 24 - Programmatte Graphteal Program Creation Exannple 

[0115] Rgure 24 lllustmtes an exemplary client graphical program that uses the nodes described above to dynam- 
15 ically create the graphical program of Figures 5A and 5B. Various sections of the Rgure 24 program are labeled In tiie 
diagram with the purpose of the code. 

[0116] As shown in Figure 24, a New VI Reference node Is used to create a new graphical program. Since no appR- 
catton reference is passed to the New VI Reference node, the new graphk^l program is created by the default local Lab- 
VIEW application Instance. The New VI Reference node outputs a reference to the new graphical program, and the 
20 Property node "reference' Input receives this reference. Tlie Property node sets properties of the graphical program, 
specifying that the user interface panel window and block diagram window of the graphical program are open. As 
described above, a user may pop up a menu to select the desired property of an object to get or set The list of dispt^ed 
properties may vary according to what type of object the reference input references. 

[0117] After the graphical program has been created and modified as described above, a New VI Object Reference 

25 node is used to create the Addition function node shown in Rgure 5B. 

[0118] Next, tiie Open VI Object Reference Node Is used to obtain a reference to tiie V Input temnlnal of the Addi- 
tion function node. The reference to tiie V input temiinal is passed to an Invoke node, whteh creates a constant value 
of 2.0 that is wired to the "x' input terminal. As described above, a user may pop up a ntenu to select tiie desired method 
to invoke on an object The list of displayed metiiods may vary according to what type of object the reference input ref- 

30 erences. Similarly, an Open VI Object Reference Node and an Invoke node are used to create a constant value of 3.0 
that is wired to the Y '^^P^^ tenDlnal of tiie Addition function node. 

[0119] Next, an Open VI Object Reference Node and an Invoke node are used to create a user interface indicator 
control that is wired to the output temiinal of the Addition function node. 

[0120] Rnally, a Property node is used to rename the label of the user interface indicator control to, The result of 
35 2.0 + 3.0 was:", as shown In Rgure 5A. Note that the reference to the user Inters Indicator control created by the pre- 
ceding Invoke node Is wired as the Input reference to this Property node. 

Roures 25 - 27: Programmatic Graphical Program Creation Example 

40 [0121] Rgures 26 and 26 illustrate a slightly more complex example of a graphical program than the program of Rg- 
ures 5A and 5B. Figure 27 illustrates a client graphteal program that uses the nodes described above to create tiie pro- 
gram shown in Rgures 25 and 26. The cTtent graphteal program of Figure 27 may be created interactively by a user, as 
described above. 

[01 22] Rgu re 25 Illustrates a user interface panel which includes a wavefbnn chart control and a button control. Rg- 
45 ure 26 Illustrates a block diagram representing the execution and data flow of the program. Each of the user interface 
controls of Rgure 25 has a con'esponding user Interface node in the Rgure 26 block diagram. The rectangular object 
61 0 with the anm^head is a while loop. The teon 612 is the condition temiinal for the while loop 61 0. 
[0123] When tills program is run, the graphteal code shown witiiin the while loop executes until the input to the con- 
dition temiinal 612 becomes "false". As shown, the user Interlace node 614 for the stop button is connected to a 
so boolean "Not" function. By default the output of the stop button user Interface node 614 is "feilse*. When a user presses 
the stop button, tiie output of the node 614 becomes "true", and the Input to the condition tennriinal 612 thus becomes 
"false". When tills happens, the program terminates, since In this example there Is no additional code to execute after 
the while loop ends. 

[0124] The Icon 616 represents a random number generator function node. The output temiinal of the random 
55 number node 61 6 is connected to the input temiinal of the waveform chart user interface node 61 8, Thus, for each iter- 
ation of tiie while loop, a random number is generated and plotted on the wavefomn chart user interface control. Rgure 
25 shows how the waveform chart may appear after several loop iterations. The teon 620 is simply a "waif function icon 
witii an Input constant of 1 00, whteh causes a pause of 100 milliseconds for each loop iteration. 



17 



EP1077404 A2 



[0125J Rgure 27 Illustrates a client graphlcai program which uses the nodes descifced above to dynamically create 
the graphical program of Rgures 25 and 26. For clarity, the client graphical program is brolcen Into sections, and the 
function of each section is described. 

[0126] In section 1 of Rgure 27, a New VI Reference node is used to create a new graphical program. Since no 
5 application reference is passed to the New Vi Reference node, the new graphical program is created by the delault local 
LabVIEW appPication instance. The New Vi Reference node outputs a reference to the new graphical program, and the 
Property node "reference* Input receives this reference. As shown, the Property node sets various properties of the 
graphical program. For example, the origin and coordinate bounds of the user interface panel (front panel) are set, the 
coordinate bounds of the block diagram window are set, etc. As described above, a user may pop up a menu to select 
10 the desired property of an object to get or set. The fist of displeyed properties may vary acconjlng to virtrat type of object 
the reference Input references. 

[01271 section 2 of Figure 27, a New VI Object Reference node is used to create the wavefomn chart user inter- 
face control. As shown, the reference to the new graphical program generated by the New VI Reference node in section 
1 is connected as the 'owner reference" input of the New VI Object Reference node. Other Inputs are also connected 

1$ which specify the type of object to create, the position to place the object, eta Once the waveform control is created, 
the New VI Object Reference node outputs a reference to the wavefom control. The property node of section 2 receives 
this reference Input and changes the Y axis range of the waveform control to range from 0.0 to 1 .0. 
[0128] In section 3 of Rgure 27, a New VI Object Reference node is used to create the stop button user interface 
control. A positioning function is used to specify the position input for the node, in order to appropriately position tiie 

20 button under the waiveform chart on tiie user Interface panel. 

[0129] In section 4 of Rgure 27, a New VI Object Reference node is used to create and position ttie while loop. 
[0130] In section 5 of Figure 27, an Open VI Object Reference node is used to obtain a reference to the user inter- 
fece node on the block diagram con-esponding to the wavefonn chart user intertiace control. As shown, a "Control Ter- 
minal" data type Is specified as the class of the object for which to obtain a reference, "Wavefonn Charf Is specified as 

25 the name of the object for which to obtain a reference, and the reference to the new graphical program is specified as 
the owner reference. Togetiier, these inputs identify the wavefonn chart user interface node. Once the reference to the 
wavefonn chart user interface node is obtained, the reference is connected to the reference input of the Invoke node 
shown in section 5. The Invoke node invokes a "Move" mettiod on tiie waveform chart user interface node, moving it 
Into the area bounded by tt^e while loop. As described above, a user may pop up a menu to select tiie desired method 

30 to Invoke on an object The list of displayed methods may vary according to what type of object the reference input ref- 
erences. 

[0131] In section 6 of Figure 27, a New V! Object Reference node is used to create the random number generator 
function. As shown, the reference to the while loop created in section 4 is used as the "owner reference" Input of the 
N®w VI Object Reference node. Thus, the random number function is created within tiie while loop. 

35 [01321 In section 7 of Rgure 27, an Invoke node is used to connect ttie random number generator function to the 
wavdbnn chart user Interface node. As shown, the reference to tiie waveform chart user interface node is connected 
to tiie reference input of tiie Invoke node. Once the user sefects ttie "Connect Wire" method as tiie metiiod to invoke, 
the Invoke node displays a list of relevant input parameters. As shown, the reference to the random number generator 
f un(^ion node Is supplied as the "wire source" input paranieter. Thus, when the Invoke node Invokes tiie "Connect Wire" 

^ method, the random number generator function node is connected to the wavefonn chart user interface node. 

[0133] In section 8 of Figure 27, a New VI Object Reference node is used to create a wait function node, an Open 
Vi Object Reference node is used to obtain a reference to the "milliseconds to wait' input tenninal of the wait function 
node, and an Invoke node Is used to create a numeric constant of 1 00 which is connected to the "milliseconds to wair 
input tonnlnal of the wait function node. 

45 [0134] In section 9 of Rgure 27, the stop button user interface node is moved inside tiie area bounded by tiie whife 
loop. Section 9 is similar to section 5 described above. 

[0135] in section 1 0 of Figure 27, a New VI Object Reference node Is used to create a "Nof boolean function inside 
the while loop. Section 10 is similar to the sections described above. 

[0136] In section 1 1 of Figure 27, an Invoke node is used to connect tiie stop button user interface node to the Not 

50 function node. Section 1 1 is similar to section 7 described above. 

[0137] In section 1 2 of Rgure 27, a Property node is used to obtain a reference to the loop condition temninal of the 
while toop. The reference to the condition tenninal is connected as the reference input to tiie Invoke node shown in sec- 
tion 12, and tiie Invoke node connects the output of ttie Not functton node to tiie condition terminal of tiie while foop, 
similarly to the sections described above. 

55 [0138] In section 13 of Figure 27, an Invoke node is used to run the newly created graphical program. As shown, 
the reference to the new graphical program is connected to the reference input of ttie Invoke node, and a "Run" method 
Is selected as the mettiod to invoke on the program. Although omitted from the above description, en-or infonnatlon is 
propagated tiirough the Rgure 27 client program, and the "error out" node shown In section 13 receives ttie final effor 
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status of the program. 

[0139] Although this example is primarily concerned with creating a new graphical program, it is noted that the 
above-described functionality also enables programmatic editing of a graphical program. References to graphical pro- 
gram object may be obtained, and various properties may be set and various methods may be invoiced to move 
5 objects, resize objects, add/remove objects, reconnect objects, etc., simllariy to the description above. In the preferred 
embodiment, any operation which a program developer may perfbmn Interactively may also be performed programmat- 
ically. 

[0140] The exemplary graphical programs of Rgures 24 - 27 utiFize the specific graphical programming API 
described above, i.e., the nodes shovi^n in Figures 10-20. This particular graphical API is exemplary only, and many 
10 alternative embodiments are contemplated. For example, instead of using property and invoke nodes such as 
described above, a graphical program may Include other types of modify nodes to modify aspects of a newly created or 
existing graphical program. 

Text-Based Client Program 

IS 

[0141] As described above, client programs may also be text-based programs. In the prefened embodiment, a text- 
based program may obtain a reference to a software component which includes an interilBce with functions or methods 
to perform the operations of the nodes described above. For example, a program may obtain a reference to an ActiveX 
component, where the interface for the ActiveX component includes a CreateNewProgram method which is corrparabte 
20 to the New VI Reference node, a GetProgramObjectReference method which is comparable to the Open VI Object Ref- 
erence node described above, etc. 

[0142] In the preferred embodiment, various types of software components are provided which enable programs of 
various languages executing on various systems to programmatically create/edit graphical programs. As is well known 
in the art, modem component-based software architecture and object oriented design techniques make it relatively 
2S Straightforward to encapsulate porttons of code and provide various Interfaces to the code. For example, a service to 
create/edit a graphical program may be exposed as an ActiveX component, a CORBA component, a Java component, 
etc In the preferred embodiment, the implementation of the nodes described above and the implementation of compo- 
nents for use in text-based programs is based on a common code base. 

30 Configuring the VI Server 

[0143] As described above, in the prefen'ed embodiment, the server program of Figure 7 is a Lab VIEW application 
instance which comprises VI Server functionality. The user can configure whbh parts of the VI Server are available to 
other applications, as well as enable or disable particular protocols and specify which server resources are exported. 
35 This section describes VI Server configuration. 

1. Server Configuration 

[0144] To configure the server for external applications, the user selects Edit»Preferences on the server machine 
40 and selects Server: Configuration from the drop down meriu. The dialog box appears as shown in Figure 28. 

[0145] The options shown in Figure 28 specify through which communication protocols other applications can 
access the VI Server TCP/IP or ActiveX protocols. If the user enables TCP/IP, the user must enter the Port number 
that client appltoations use to connect to the server. When the user allows other appfications to connect using TCP/IP, 
the user should also configure which Internet hosts have access to the server. See the TCP/IP Access Conf^uratlon 
45 section for more infonnation. For more Information about the VI server ActiveX Interface, refer to U.S. provisional patent 
application Seriai No. 60/056,528 titled "System and i\^ethod for Accessing Object Capabilities in a Graphical Program* 
filed 8/21/97, whose Inventors are Ram Kudukon, Robert Dye, and Murali Parthasarathy, whk:h is hereby incorporated 
by reference. 

[0146] With Server: Configuration selected, the user also specifies which sen/er resources are available to appll- 
50 cations that access the VI Server. The following sen/er resources are available: 

VI Calls alk)ws applications to make calls to Vis on the server. When the user allows other applications access to 
Vis, the user should also configure which Vis they have access to. See the section Exported Vis Configuration for 
more information. 

55 VI Methods and Properties allows applications to read and set the properties of Vis on the server. When the user 
allows other applications access to Vis, the user should also configure which Vis they have access to. See the Sec- 
tion Exported Vis Con^guration for more infonnation. 
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[0147] Application Methods and Properties allows applica^ons to read and set the properties of the server. 
[0148] In the example of Figure 28, TCP/IP server access Is enabled for port 5151 and the ActiveX server access 
is disabled. The server allows remote clients to call Vis, but does not allow access to Vt or application methods and 
properties. 

5 [0149] The defeult server settings have ActhreX enabled and TCP/IP disabled. By default, VI Calls Is enabled, but 
Vi Methods and Properties and AppHcation Methods and Properties are disabled. 

2. Exported Vis ConfiqiuratiQn 

10 [0150] The user may specify which Vis remote applications can access. To configure the exported Vis, the user 
selects Edlt»Preferences on the server computer, then selects Serven Exported Vis from the drop down menu. The 
dialog box appears as shown in Figure 29. Although not shown in Rgure 29, the user may also specify various options 
which allow or disallow client programs to perfonn particular operations regarding creating/editing graphical programs. 
For example, the user m^ set up the server to allow clients to create new programs, but disallow the editing of existing 

75 programs, or the user may set a password required to edit existing programs, etc. 

[0151] The Server: Exported Vis options allows the user to specify which Vis other applications can access 
through the VI Server. The Exported Vis fist specifies which Vis are exported. To change an entry, the user selects it 
from the list, then types into the text box at the tight of the Exported Vis list To specify whether remote computers can 
or cannot access that VI, the user clicks on the Allow Access or Deny Access radio buttons. The user clicks the Add 

20 button to Insert a new entry after the cun^nt selection. The user clicks the Remove button to delete the current selec- 
tion. The user clicks and drags an entry to change Its position within the Exported Vis list If an entry allows access to 
Vis, a check mark appears next to the entry. If an entry denies access to Vis, a 'cross out" symbol appears next to the 
entry. If no symbol appears next to the entry, the syntax of the entry is Incorrect. 

[0152] Each entry in the list describes a VI name or a VI path and may contain wildcard characters (see the para- 
25 graph below on wildcard characters). Entries that contain path separators are compared against VI paths, while entries 
that do not contain path separators are compared against VI names only. When a remote client tries to access a VI, the 
server examines the Exported Vis list to determine whether to grant access to the requested VI. If an entry in the list 
matches the requested VI, the server either allows or denies access to that VI, based on how that entry is set up. If a 
subsequent entry also matches the VI, its access pennissk>n is used in place of the previous pemnlssion. If there is not 
30 a VI in the list that matches the requested VI, access to the VI is denied. 

[0153] As mentioned earlier, the user can use wildcard characters in the Exported Vis Hst so an entry in the list 
matches more than one VI. The following wildcard characters can be used: 

'?' matches exactly one arbitrary character, except for the path separator. 
35 matcheszeroornrtorearbitrarycharBCterB, except for the path separator. 

together match zero or more arbitrary charscters, including the path separator. 

[0154] it the user wants to match a VI with a name that contains a wildcard character, the user must escape that 
character using V on the Macintosh and UNIX platforms, and using on Windows. 
40 [0155] The following tables shows some exanples of Exported VI list entries. The examples use UNIX path sepa- 
rators. 



Table 1 



Server TCP/IP Access Entries 


* 


Matches all Vis 


/usr/labviewr 


Matches all Vis in the directory /usr/iabview/. 


/usnftativiewr * 


Matches alt Vis in the directory /usr/iabview/ and any of its sub-directories. 


Test.vt 


Matches any VI named TesLvi". 


*expon* 


Matches any VI with a name that contains the string "export". 


OKV? 


Matches any VI with the name 0K7. 



55 

[0156] In Figure 29, all Vis in the C: MabvievAsen^er directory are exported. All Vis in the c: MabvieWVtest directory 
and all its sub-directories are exported as well, with the exception of the VI c:MabvieW\test\private.vi. Additionally, any VI 
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that begins with the string srvr_ and ends with the string .vl is exported. No VI that begins with the string local, and ends 
with the string .vi is exported, even if ft is located within the c: \tabvieW\server directory. 
[0157] The default Exported Vis settings allow access to aO Vis. 

5 3. TCP/IP Access Configuration 

[0158] When the user allows remote applications to access the VI Server using the TCP/IP protocol, the user 
should specify which Internet hosts have access to the server. To configure the clients that have access, the user 
select Edit»Preferences on the server machine and selects Server TCP/IP Access from the drop down menu. The 

10 options appear in the Preferences dialog box as shown in Rgune 30. 

[0159] Selecting Server: TCP/IP Access allows the user to specify which clients can access the VI Server. The 
TCP/IP Access List describes clients that either have access to or are denied access to the LabVIEW server. To change 
an entry, the user selects it from the list, then types into the text box at the right of the TCP/tP Access List The user 
clicks on the Allow Access radio button to allow the client to access the server. The usercltcks the Deny Access radio 

15 button to deny the cfient access to the server. The user clicks the Add button to insert a new entry after the current 
seledjon, the user clicks the Remove button to remove the current selection from the list. The user clicks and drags an 
entry to change its positton within the TCP/IP /Access List. If an address is allowed access, a check mark appears next 
to the entry. If an address Is denied access, a 'cross ouT symbol appears next to the entry. If no symbol appears next 
to the entry, the syntax of the entry Is Incorrect 

20 [01 60] When a client tries to open a connectton to the server, the server examines the entries In the TCP/IP /Vccess 
List to determine whether it grants access to the client If an entry in the list matches the clients address, the server 
either allows or denies access, based on how the user set up the entry, if a subsequent entry also matches the client's 
address, its access pemilssion is used in place of the previous permission. (For example, in Rgure 29 above, 
a.testsite.com in the TCP/IP Access List is allowed access even though the list indicates that all addresses ending In 

25 .testsite.com are not allowed access. See the paragraph on wildcards later in this document) If no entry matches the 
client's address, access is denied. 

[0161] An Internet (IP) address, such as "130.164.123.123", may have one domain name (such as "www.nat- 
instcom") or more associated with it The conversion from a domain name to Its connesponding IP address is called 
name resolution. The conversion from an IP address to Its domain name is called name lookup. 

30 [0162] Name lookups and name resolutions are done through system calls that access domain name system 
(DNS) servers on the Internet A name lookup or resolution can fail when the system does not have access to a DNS 
server, or when the address or name is not valid. A resolution problem occurs when an entry contains a domain name 
that cannot be resolved into an IP address. A lookup problem occurs when an entry contains a partial domain name, 
such as ".natinstcom". and the lookup for the clients IP address fails. 

35 [0163] The Strict Checking option detenmlnes how the server treats access list entries that cannot be compared 
to a clients IP address because of resolution or lookup problems. When Strict Checking is enabled, a denying access 
list entry in the TCP/IP Access List that encounters a resolution problem is treated as if It matched the client's IP 
address. When Strict Checking is disabled, an access list entry that encounters a resolution problem is ignored. 
[0164] To specify an Internet host address, the user enters its domain name or IP address. The * wildcard can be 

40 used when specifying Intemet host addresses. For example, the user can specify all hosts within the domain 
domain.com with the entry * .domaIn.com. The user can specify all hosts in the subnet whose first two octets are 
130.164 with the entry 130.1 64.*. The entry * matches all addresses. 
[0165] The following table shows some examples of TCP/IP Access List entries. 

45 

Table 2 



55 



Server: TCP/IP Access 


* 


Matches al! hosts. 


test.site.com 


Matches the host whose domain name is testsite.com. 


*.site.com 


Matches all hosts whose domain name ends with *.srte.com. 


130.164.123.123 


Matches the host with the IP address 130.164.123.123. 


130.164.123.* 


Matches all hosts whose IP address starts with 1 30.1 64.123. 



[0166] In Rgure 30. all hosts In the slte.com domain have access to the server, with the exception of all hosts in the 
test.site.com domain. Additionally, the hosts atestslte.com, b.testsite.com and 130.1 64.123.123 have also access to 
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the server. The host publlc.slte.com does not have access, even though It Is In the slte.com domain. 

[0187] The default TCP/IP Access settings allow access only to clients on the server machine. 

[0168] It is noted that, If the VI Server runs on a system that does not have access to a DNS server, domain name 

entries should not be used in the TCP/iP Access list • requests to resolve the domain name or an IP address will fall, 

slowir^ down the system. For perfonmance reasons, place frequently matched entries toward the end of the TCP/IP 

Access List 

Local Client^Server Communication 

[0169] When a client on a first computer accesses an instance of a VI Server located on the first computer, I.e., 
accesses a local VI, the respective access node. e.g., the New VI Reference node, the Invoke node, the Property node, 
etc., operates to manipulate or access the VI in a similar manner as if the VI were in the dlent graphical program. 
[0170] Although the system and nrtethod of the present invention has been described In connection with the pre- 
ferred embodiment, it Is not Intended to be limited to the specific fomi set forth herein, but on the contrary, ft is intended 
to cover such altematives, modifications, and equivalents, as can be reasonably included wWiln the spirit and scope of 
the invention as defined by the appended claims. 

Claims 

1. A computer-implemented mrthod for programmatlcally creafing a graphical program, comprising: 

creating a first program, wherein the first program specifies creation of a new graphical program, wherein the 
first program is executable to programmatically create the new graphical program; 
executing the first program; and 

programmatically creating the new graphical program In response to said ©cecuting the first program. 

2. A system for programmatically creating a graphical program, comprising: 

a computer system including a CPU and memory; 

wherein the memory stores a first program, wherein the first program specifies creation of a new graphical pro- 
gram, wherein the first program is executable to programmatically create the new graphical program; 
wherein the CPU is operable to execute the first program to programmatically create the new graphical pro- 
' gram. 

3. The method or system of any of claims 1 or 2, wherein said programmatically creating the new graphteal program 
creates the new graphical program without any user Input specifying the new graphical pnogram during said creat- 
ing. 

4. The method or system of any of dalms 1 or 2, wherein the new graphical program comprises a plurality of intercon- 
nected nodes which visually indicate functionality of the new graphical program. 

5. The method or system of any of claims 1 or 2, wherein the new graphical program comprises a diagram portion 
comprising a plurality of interconnected nodes and a user Interface portion; 

wherein said programmatically creating the new graphical program Includes creating the block diagram portion and 
the user interface portion. 

6. The method or system of any of claims 1 or 2, wherein the new graph»al program is a virtual InstrumenL 

7. The method or system of any of claims 1 or 2, wherein said executing the first program occurs In a first computing 
environment; 

wherein said first computing environment is connected to a second computing environment; 

wherein said executing the first program comprises sending information from the first conriputing environment to the 

second computing environment; 

wherein the new ^hteal program Is created In the second computing environment. 

8. The method or system of any of claims 1 or 2. wherein said programmatically creating the new graphical program 
comprises: 
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creating a pluraTity of gmphtoal program objects in the new graphical program in response to said executing the 
first program; and 

interconnecting the piurality of grE^hicai program objects in the new graphicai program in response to said exe- 
cuting the first program; 

5 wherein the interconnected piurality of graphical program objects comprise at least a portion of the new graph- 

ical program. 

9. The method or system of any of claims 1 or 2, wherein said programmatlcaily creating the new graphical program 
comprises: 

10 

creating one or more user interface objects in response to said executing the first program, wherein the one or 
more user Interface objects perform one or more of providing input to or displaying output from the new graph- 
ical program. 

15 1 0. The method or system of any of claims 1 or 2, wherein, in response to said executing the first program, the first pro- 
gram is operable to interface with a server program; 

wherein the server program is operable to programmatically create the new graphical program in response to said 
Inteifaclng. 

20 11. The method or system of claim 1 0, wherein the server program Is an application instance of a graphicai program- 
ming development environment 

12. The method of claim 1 0, 

wherein said executing the first program occurs on a first computer system; 
25 wherein the server program executes on a second computer system. 

13. The system of claim 10, wherein said computer system Is a first computer system, the system further comprising: 

a second computer system including a CPU and memory; 
30 wherein the first computer system is connected to the second computer system via a networl<; 

wherein the memory of the second computer system stores the server program; 

wherein the CPU of the second computer system is operable to execute the server program to programmati- 
caDy create the new graphical program In response to said interfacing. 

35 14. The method or system of any of daims 1 through 8, wherein the first program is a firet graphical program. 

15. The method or system of claim 14, wherein the first graphical program includes at least one object creation node 
for programmatically creating at least one graphical program object in the new graphical program; 

wherein said programmatically creating the new graphicai program comprises including the at least one graphical 
40 program object in the netw graphical program in response to said executing the first graphical program. 

16. The nnethod or system of daim 15, wherein the first graphical program further includes a property node; 
wherein the property node is operable to get or set a property of the graphical program object in response to said 
executing the first graphical program. 

45 

17. The method or system of claim 15, wherein the first graphical program further Includes an invoke node; 
wherein the invoke node is operable to invoke a method on the graphnal program object in response to said exe- 
cuting the first graphical program. 

so 16. The method or system of claim 1 7, wherein the invoked method connects the graphical program object to another 
graphical program object in the new graphicai program; 

wherein said connecting the graphbal program object to said another graphical program object comprises connect- 
ing an input of the graphicai program object to an output of said another graphical program object 

55 1 9. The method or system of claim 1 4, wherein the first graphical program includes a graphical program creation node 
for programmatfeally creating the new graphical program; 

wherein the first graphical program includes at least one object creation node for programmatically creating at least 
one graphteal program object In the new graphical program; 
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wherein said executing the first graphical program includes: 

executing the graphical program creation node, wherein said executing the graphical program creation node 
causes creation of the new graphical program; and 
s executing the object creation node, wherein said executing the object creation node causes inclusion of the 

graphical program object In the new graphical prog^an^ 

20. A memory medium comprising a first program, wherein the first program specifies creation of a new graphical pro- 
gram, wherein the first program is executable to programmatlcally create the new graphical program. 

10 

21. The memory medium of claim 20, wherein said programmatically creating the new graphical program creates the 
new graphical program without any user input specifying the new graphical program during said creating. 

22. The memory medium of any of dalms 20 or 21 , wherein the new graphical program comprises a plurality of inter- 
15 connected nodes which visualty indicate functionality of the new graphical program. 

23. The memory medium of any of claims 20 through 22, wherein the new graphical program comprises a diagram por- 
tion comprising a plurality of interconnected nodes and a user interiace portion; 

wherein said pmgrammatically creating the new graphical program includes creating the blodc diagram portion and 
20 the user Interliace portion. 

24. The memory medium of any of claims 20 through 23, wherein said programmatically creating the new graphical 
program comprises: 

25 prcgrammatlcalty creating a plurality of graphical program objects in the new graphical program; and 

programnrmticalty interconnecting the plurality of graphical program objects in the new graphical program; 
wherein the interconnected plurality of graphical program objects comprise at least a portion of ttie new graph- 
ical prc^ram. 

30 25. A computer-Implemented method for programmatically modifying an existing graphical program, comprising: 

creating a first program, wherein the first program includes a reference to the existing graphical program, 
wherein the first pmgram is executable to programmatically modify the existing graphical program; 
executing the first program, and 
35 programmatically modifying ttie existing graphical program in response to said executing the first program. 

26. A system for programmatically modifying an existing graphical program, comprising: 

a computer system including a CPU and memory; 
40 Wherein the memory stores a first program, wherein the first program includes a reference to the existing 

graphical program, wherein the first program is executable to programmaticatly modify the existing graphical 
program; 

wherein the CPU is operable to execute the first program to programmatically modify the acisting graphical pro- 
gram. 

45 

27. The method or system of any of clahis 25 or 26, wherein said programmatically modifying the existing graphical 
program modifies the existing graphical program without any user input specifying the modification to tiie existing 
graphical program during said modifying. 

so 28. The method or system of any of claims 25 or 26, wherein the existing graphical program comprises a plurafity of 
interconnected nodes which visually indicate functionality of tiie existing graphical program. 

29. The method or system of any of claims 25 or 26, wherein the existing graphical program comprises a diagram por- 
tion comprising a plurality of interconnected nodes and a user interface portion; 

ss wherein said programmatically modifying the existing graphical program Includes modifying the diagram portion 
and the user interface portion. 

30. The method or system of any of claims 25 or 26, wherein tiie esdsting grapliicat program includes a plurality of 
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graphical program objects; 

wherein said modifying the existing graphical program comprises modifying one or more graphical program objects 
in the existing graphical program in response to said executing the first program. 

31. The method or system of any of daons 25 or 26» wherein the existing graphicai program Includes a plurality of user 
interface objects; 

wherein said modifying the existing graphical program comprises modifying one or more user Interface objects in 
the existing graphical program in response to said executing the first program. 

32. The method or system dS any of datms 25 through 31, wherein the first program is a first graphical program. 

33. The method or system of claim 32, wherein the first graphicai program Includes at least one modify node; 
wherein the mocfily node Is executable to modify one or more graphicai program objects in the existing graphical 
program. 
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